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It is important to enable reasoning about the meaning and possible effects of updates to ensure that the 
updated system operates correctly. A formal, mathematical model of dynamic update should be developed, 
in order to understand by both users and implementors of update technology what design choices can 
be considered. In this paper, we define a formal calculus updaten, a variant extension of higher-order 
n calculus, to model dynamic updates of component-based software, which is language and technology 
' independent. The calculus focuses on following main concepts: proper granularity of update, timing of 

pLn ■ dynamic update, state transformation between versions, update failure check and recovery. We describe a 

5/5 ' series of rule on safe component updates to model some general processes of dynamic update and discuss 

O . its reduction semantics coincides with a labelled transition system semantics that illustrate the expressive 

power of these calculi. 
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1 Introduction 

Dynamic updated 051 is a general, software-based technique: there is no need for redundant hardware or 
special-purpose software architecture, and application state can be naturally preserved between updated ver- 
sions, so that current processing is not compromised or interrupted. Most current works about software 
update(e.g. 0] |7j [U [TUJ O) concentrate on techniques and implementations of bug-fixes or performance 
enhancements. They implement some well-established update methods for global synchronization of local 
updates or distributed updates. But they lack both simplicity and generality and it is not clear what properties 
are actually guaranteed. Therefore, we believe a formal, mathematical model of dynamic update should be de- 
veloped, in order to understand what design choices can be considered, and what impact they have on update 
complexity and scalability. There a few formalization works have been carried out to support the correctness 
and consistency derivations of dynamic update (e.g. [3] [15] El. Nevertheless, we are not aware of past efforts 
that have well formalized the models for timing of update, state transformation, and update failure recovery. 

To be able to reason and ensure properties about system specifications supporting dynamic component 
updates, we need mathematical tools. Process calculi are one suitable tool, providing not only a description 
language, but a rigorous semantics as well, allowing the proof of relevant properties. In this paper, we de- 
fine a formal calculus updaten to model dynamic updates of component-based software, which is language 
and technology independent. This calculus is an extension of the asynchronous, polyadic and higher-order 
7r-calculus based on the fact that dynamic updates can be seen as interactive behaviors, message-passing asyn- 
chronously, within a component-based system. Some important aspects on dynamic component update, which 
ranging from proper granularity of update, timing of dynamic update, state preservation and transformation, 
and update failure check and recovery, will be modeled and reduced in our calculus. 

The rest of this paper is organized as follows. In Section 2, we review the main considerations behind 
different constructs of the updaten calculus, and then present the syntactical and structural descriptions of 
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update?: calculus. We describe in Section 3 a series of rule on safe component updates to model some gen- 
eral processes of dynamic update and some well-defined update mechanism. The reduction semantics of the 
updaten calculus are defined in Section 4, and show that the reduction semantics coincides with a labelled 
transition system semantics, under sufficient conditions on the interaction of processes with the environment, 
that illustrate the expressive power of this calculi. In section 5, we discuss related works on mechanisms and 
formalism of dynamic updates. Section 6 concludes the paper with a discussion of further work. 

2 The updaten Calculus 

In this section, we firstly motivate some design choices by introducing informally the main elements about a dy- 
namic component update and the main constructs of the updaten calculus. Then we present the syntactical and 
structural descriptions of updaten calculus, as a calculus for modeling dynamic updates of component-based 
software, with a location concept to model the hierarchical composition of components, a process sequence to 
model the timing of updates, an accompanied process to model executed log of updates, and a state increment 
or decrement mechanism to model state preservation and transformation. 

2.1 Design Choices 

The updaten calculus inherits ideas from numerous previous studies, included safe and timely dynamic updates iflOl 
13], and higher-order calculus(specially, Kell calculus lfl2l ). It is built as an extension of the higher-order n- 
calculus, and observes several main design principles which we consider important for a foundational model 
of dynamic component update: trusted update sources, reasonable timing of update, and consistent state trans- 
formation. 

In updaten calculus, exactly as in Kell calculus, we use the hierarchical and programmable locality concept 
as a primitive form of component that can be used simultaneously as a unit of modularity, of isolation, and 
of passivation(the ability to freeze and marshal a component during its execution). The updaten calculus is 
in fact a family of higher-order process calculi with a special update locality, which shares the same basic 
operational semantics rules with the other calculus, but differ in the language used to define specified update 
mechanisms in input and output constructs, and affiliate a state description for each process. Furthermore, 
contrarily to some existing proposals, we interpret the names declared inside a locality as private resources, 
that should remain local to that locality. Neither do we include an axiom of form l[(vn)P] = (vn)l[P] in 
structural congruence, nor do we implement name extrusion across locality boundaries along reduction steps 
that would require it(similar to some existing implementations of 7r-calculus-related process algebras|5 ]). This 
design choices avoid ambiguous diversity of reduction pathes in located process l[P], and enable safety of 
programmable locality where the resources are not extravasate outside their owner. 

The timing of an update, as many past researchers have observed, is critical to ensuring the validity (6l|7l- 
This synchronous update primitive dictates when an update can occur,and makes it easier to understand the 
states of program which an update is applied to than the alternative asynchronous approach, in which an update 
could occur at any time. Some researches[7 , 8 ] have proved that synchronous updating makes it easier to write 
correct updates. So some safe update points specified by a programmer or implementor of updated software 
can express explicitly the update requirements and favor to derive safe and timely software updates. In our 
calculus, the process sequence P ; Q forces a temporal order between the two operands: process Q will be 
activated only after successful completion of P. Through the process sequence, safe update points can be set 
in feasible locations of whole programs, thus the timing of update is enforced by some temporal operands of 
the sequential composition operator. 

Without care, after several updates the state of an updated system can become confusing, particularly when 
updates are in terms of binary patches. Replacements and transformations must not interfere with application 
access to the objects, and must be performed efficiently in both space and time. However, the state to be 
transformed might be corrupted (e.g., update for bug fixes) and detecting and transforming a corrupted state 
to a non-corrupted state is the quintessential state transformation problem. For simplicity and without loss of 
generality, in this paper, we assume that the state is not corrupted and the transformation can be done safely 



so that important consistency is not broken. We propose an approach to associate a state information to each 
process, where all instant output actions of a process are recorded. In our calculus, a related state 8 is defined 
for each process. The process state is composed of some output actions generated after execution of the 
process, which denote the results of execution and are expressed through the names as channels or locations. 

2.2 The Syntax 

The syntax of update?: calculus is given in Figure Q] Similar to standard 7r-calculus processes, we use to 
denote a null process that does not perform any action, X to denote a unknown process which is waiting for an 
assignment, P | Q to denote the parallel composition of two processes to allow processes to interact, and (vn)P 
to denote the name restriction, in which the creation of a fresh name n whose initial scope is the process P. 
The process sequence P ; Q forces a temporal order between the two operands: process Q will be active only 
after successful completion of P. In this process sequence, a sequence operator ; split two processes, where 
process P is assigned as a predecessor of the operator ; and then process Q is a successor of this operator. 

The interfaces of component are modeled by channels, thus the output and input behaviors can be expressed 
through some actions on channels. The channels can carry extensible records, which model message exchanges 
between components through input and output interfaces. An output on channel a is noted a(u>), where a> is a 
constant argument that can ba a name n or a process P. Specially, no continuation is to afflicted each output 
action because we consider the output process is parallel to other processes. Similar to Kell calculus, we use 
the located process concepts, by the term 1[P], to model software components for hierarchical composition. In 
the term l[P], I is the name of the locality, that is, a identifier of location in which the components are stored 
before the composition, and P is the process identifier of a single process, a process composition or a process 
sequence executing at location /. 

It is worth of notice that in an input trigger £ * P, the operator between input pattern £ and continuation 
process P is * rather than •, used in standard 7r-calculus. There exist two cases for this operator: > and o, where 
the former is a disposable trigger operated only once and however the latter can be preserved during a reduction. 
Our calculus implement the primitive for recursion or replication through the o operator, which can model 
asynchronous message passing between concurrent components. For example, the process a(Q) \ a{X) o P will 
be induced to a(X)oP | P{Q/X), where {Q/X} denotes a capture avoiding substitution of process variable X with 
process Q. a(x)*P, a{X)*P respectively stands for a process willing to acquire a resource: this can mean either 
receiving a first-order or higher-order message. The input prefix £ and restriction operator v act respectively as 
a binder in the calculus. We write fn(P) and fv(P) respectively for the free names and free variables of process 
P. Furthermore, we use the standard notions of free names of processes and of a-equivalence. We note P - a Q 
when two terms P and Q are a-convertible. 

The channel of transmitting the update packages is specified by the name up, thus its output process 
is expressed through the term up(Z, P) in our calculus. For the receiver of update messages, in which the 
updates are executed concretely, we define the pattern parameterized process term up(Z, X)#R o P to receive 
the matched update package on channel up, and then to activate and execute the actual updates. Noteworthily, 
it is possible that an update falls failure ascribe to some inadequate checks of compatibility before update and 
some accidents during update. Thus we introduce a concept of update log, which allows to incrementally build 
the log of updates when each update execution. In the term up(Z, X)#R o P, the sub-expression #P, in which 
R is an accompanied process, is used to associate to each update a process that records the trace to be stored 
upon update message reception. When the update of a process P incurs a recoverable failure, we block the 
execution of P. This is modeled through the blocked process |[P]] that behaves as P but cannot be activated 
until it is restored when the execution of a well-defined update failure recovery (or rollbacking). 

A state 8 is a multiset of names that represents the output actions or resources visible to the update when 
it was initiated. In the following, we write 8 W {a} for the multiset 8 enriched with the name a and 8\8' for the 
multiset obtained from 8 by removing elements found in 8', that is the smallest multiset 8" such that 8 c 8'*±)8". 
The symbol stands for the empty multiset while {a n \ is the multiset composed of exactly n copies of a, where 
{a } - 0. The evaluation of state is 8 = {a}, which a is an output action, if a(n) or a(P) is a valid process of the 
current updated components, and 8 - {/}, which / is an output resource, if Z[P] is a valid process in the current 
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Figure 1: Processes and states of updaten calculus. 

updated components. 



3 Dynamic Component Update in updaten 

We describe in this section a series of rule on safe component updates to model general process of dynamic 
updates and possible update failures. And the time selection of dynamic update and the state preservation 
and transformation between versions also are enforced in our calculus. We first define formally two affiliated 
functions about state matchability and process compatibility as follows. 

Definition 1. Two process state 5, 6' are said to be matchable (noted by match(S, 5')), if S c 8' which means 
that 5, 5' are same or all output actions visible to the update in set 5 are also included in the set 6'. 

Definition 2. Two processes P, Q are said to be compatible (noted by COmp(P, Q)), if all output and input 
interfaces of the constituent components in process P are compatible with those in process Q. 

3.1 Safe Update of Component 

We assumed that the component is abstracted with a located process which can be a composition of multi- 
components, thus in the output term up(Z, P) , I is a locality identifier of the enclosing updatable components, 
which is defined by the programmer of update packages. That is, the identifier and its version information of 
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Figure 2: Reduction semantics of safe component updates. 



a to-update component specified through the name / in the update package. However, P is a process constant 
which specifies the concrete contents of the update package. Accordingly, in the input process term up(Z, X)#Ro 
P, I is location constant which can includes some version information, etc., used to specify a safe location of 
update. And the operator o means that the safe location is replicative and can be preserved during a update. 

During a component update, the two locality identifiers of output and input interface for updates will be 
compared to ascertain whether there is a pending update for the current component, through the check of name 
matchability and version correctness. Specially, if the version number of provided update package is larger than 
the one of current component, which founded on the assumptions of update in last section (in which we don't 
consider the backwards updates but only forwards updates), a safe update is triggered as illustrated in the rule 
(R. Update. Ok). Then the process P transmits the actual update operations to the target components k[Q], 
and this is expressed by a capture avoiding substitution {P/X} in rule (R. Update. Ok). And the states of new 
and old processes keep consistent during the update, which are expressed with state matchability match(5, 8'). 
The sub-expression #R is used to associate to each update a process R{P/X} that stores the associated runtime 
states upon update message reception. If the update is successful, the blocked process R{P/X) will not be 
activated to promote the normal execution of program. 

On the contrary, in rule (R. Update. UnMat), because the provided update package is incompatible with 
the current component, by which either smaller version number or unmatched component identifiers, the pro- 
cess P is not activated and the target components will perform its intrinsical functions as normal. However, 
even if the version numbers and component identifiers are validated, the update will be restrained when the 
injected process P and the to-update process Q are incompatible as illustrated in rule (R. Update. Rest). 

We assume that each update is well-defined, can be recovered from failures. The process R is an accom- 
panied log process to store the executed actions of an update, which to be backtracked in case the update fails. 
To account for possible failures of the update process, the accompanied process R, which records the trace in- 
formation of executed update and becomes critical part of the recovery process of the update., will be activated 
for backtracking and recovery to abort invalid updates. The process R has no activity until a failure occurs, 
becoming then the recovery process R. When an update action occurs, the associated log process is stored 
and becomes part of the recovery process of the update. In rule (R. Update. Fail), the version numbers and 
component identifiers are validated and the injected process P and to-update process Q are compatible, but the 
two states of new and old processes are inconsistent during the update. It means that the update of process Q 
incurs a recoverable failure, we block the execution of Q{P/X). This is modeled through the blocked process 
|[2{P/X}]| that behaves as Q{P/X} but cannot be activated until it is restored from a well-defined update failure 
recovery (triggered by the recovery process R{P/X}). 



3.2 Timing of Update 



In our calculus, the process sequence P ; Q forces a temporal order between the two operands: process Q will 
be activated only after successful completion of P. Through the process sequence, safe update points can be set 
in some feasible locations of whole programs, thus the timing of update is enforced by this temporal operands 
of the sequential composition operator. For example, if a update can occur after the execution of process P 
and before the execution of process Q, then as process sequence P ; up(k, X)#R o k[Q], a safe update point will 
be assigned to the process Q. During the execution of process P, a update corresponding to this update point 
will be pended until the process Q is about to be activated. On the contrary, if the process Q is not the process 
which is about to be activated immediately in next time, then this update will keep pending. By dictating when 
an update can occur, makes it easier to understand the states of the program which an update is applied to. And 
through this mechanism, we allows the lazy updates[4J which the component is not updated until the to-update 
process is about to execute. 

3.3 State Transformation 

State transformation is meaningful to map a state of the old application to a state of the new one. In our 
calculus, a state 8 is a multiset of names that represents the output actions visible to the update when it was 
initiated. At the time of an update, a well-defined state transformation function is executed from component 
entry points. Then the state 8 recorded in the updated process (the state at the initiation of the update) will 
be compared with the current state 8' (the mapped state when the update ends) to check if the update have 
concurrently made changes to the updated components for consistency. If the new state 8' is consistent with 
the old one 8 (that is, they satisfy the Definition 1, denoted as match(5, 8')), the updated component will 
be able to preserves the old execution. In other words, the component update is successful as illustrated 
the rule (R. Update. Ok). Otherwise, if the two states 8 and 8' are verified to be inconsistent (denoted as 
!match(5, 6')), as in the rule (R. UPDATE. FAIL), the update will fall into be fail to activate the update recovery 
process R{P/X}). 

4 Operational Semantics 

The operational semantics of a process algebra is traditionally given in terms of a labelled transition system 
describing the possible evolution of a process. In general, it is not easy to define directly a labelled transition 
system. The manipulation of names and the side conditions in the rules are non-trivial. On the other side, if 
the reduction system is available, the corresponding labelled transition system can be found. Furthermore, by 
showing the correspondence of both the reduction system and the labelled transition system it is possible to 
prove the correctness of the latter. 

4.1 Structure Congruence 

The structural congruence relation, written by =, equates all processes we will never want to distinguish for 
any semantic reason. 

Definition 3. Structure congruence = is the smallest equivalence relation on execution process that satisfies 
the a-conversion law, and the axioms given in Figure\3\ 

Noted that we do not allow as a successive neutral element, as in rule P ; = P, because after the 
execution of process P, its successor split with a sequence operator ; is not always executed. Because the 
blocked process |[P]] behaves as P but cannot be activated until a well-defined update failure recovery is 
executed, the v restriction operation, as in rule (S.Nu.Blk), can extrude to the top level of a block. And it 
behaves as P when a blocked process |[P]| is activated, so we use the rule (S.Exec.Blk) to indicate that the 
execution of process [[P]] and P are not distinguishable. And it should be clarified that besides the process 
output itself, the output a(P) also delegate name output d{n), located process output l[P] and update provision 
up (I, P) in this rule. 
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Figure 3: structure congruence relations of processes. 



Notice also that the Ambient-like rule l[(vx)P] * Q = (vx)l[P] * Q and l[(vx)P] = (vx)l[P] are not allowed 
when x <f. {/} U fn(0 to enable the safety of programmable locality where the resources are not extruded 
outside their owner. Furthermore, in rule (S.Ptn.In), (S. Update. Rev), (S. Alpha), and (S. Context), we 
rely respectively on the structural congruence relation on input patterns, update reception, a-conversion, and 
process context. 



4.2 Reduction Semantics 

Figure |4] gives the reduction semantics of processes in updaten calculus. A reduction is of the form P : 5 — > 
P' : 8' where 8 is the state of process P and 8' is an evolution of 8. For simplicity, the state 8 only records 
the names of all output actions visible to P when reduction happens. It grows when an output representing an 
internal processing result is produced along with the execution of processes, and shrinks when an output or re- 
source is consumed, as illustrated in rule (R.Out.Name), (R.Out.Proc), (R.Out.Pass), (R. Update. Prv), 
(R. In. Name), (R.In.Proc) and (R. In. Pass) where the process constant P has state 8. 

Specially, the shrinkage semantics of state are also reflected with rules (R. Update. Ok), (R. Update. Rest), 
(R. Update. UnMat) and (R. Update. Fail) in Figure [2] And these reduction rules govern the dynamic up- 
dates of components, which allow to recover a failed update since those stored state information are not dis- 
carded. This design choice was influenced by an expected feature of update handlers: the possibility to recover 
updates locally spoiled or completed failures, where by completed failure we mean a update giving rise to 
the recoverable failures of several constituent components in a application module. This feature would not 
have problems of feasibility in a real system, since it could be associated to our calculus a distributed garbage 
collection ifTTTl to remove recoveries of update no longer essential. 

In rule (R.COMM), it can be concerned that the process P provides some consumable resources, denoted 
by state 8, and then the process Q consumes these resources. However, in process P ; Q, besides the sequence 
in time, there is no interaction between them. So the evolution of process P and Q can be respectively fulfilled, 
as in rule (R.Seq.Fst) and (R.Seq.Both), where the latter explicitly expresses temporal order between 
them. Rule (R.Res) and (R.Blk) deal respectively with the initiation of an located process and an blocked 
process: an ongoing located resource or process block is created which holds the newer evaluation state 8'. 
Furthermore, in equivalence rule (R.EQV) and cr-conversion rule (R. Alpha), the two reduction relations 
depend on a matchability relation, match, which associates pairs consisting of two states. As illustrated in 
Definition 1, this matchability relation is assumed that define how a single state matches the other single state 



a(n) : {a} -> : (R.Out.Name) a{P) : {a} W 6 : (R.Out.Proc) 



/[P] : (/} i±J 5 -> : (R.Out.Pass) up (/, P) : {1} W 5 -* : (R. Update. Prv) 

(a(n) | fl(jc) > P) : 6 W {a} -> P{n/x} : 5 (R.lN.NAME) 
bn(X) n MP) = <p 

(R.In.Proc) 
(R.In.Pass) 
(R.Comm) 



(a(P) | 


a(X) > Q) : 6 W {a} - 


* QiP/X} 


: S 




bn(X) n fn(P) = 






Q[P] 1 


P1>0):<5W{')- 


* Q{P/X} 


: 8 


P:6 


i W 5 -» P' : <Si Q: 




62 



P \ Q : 6i V 62V 6 ^ P' \ Q' : 61 W 6 2 



P : Si -» P' : Si Q -Si^Q' :S' 

(R.Par.L) 2 (R.Par.R) 



P\Q:Si^S 2 ^*P'\Q:S\^S 2 P I Q : 61V 5 2 -> P | Q : tfi W <5 2 



P : <5i -> P' : <j; P : <5i -> P' : <K g : 5 2 -> Q! : 8' 

(R.Seq.Fst) — ^ } (R.Seq.Both) 



P ; Q :6 1 ^ P' ; Q :S\ ~ P ; g : Si W & -»■ J" ; 0! : ^ W ^ 

P:6^P':S' , P:6-*P':S' , 

(R.Res) (R.Blk) 



Z[(vx)P] : 5 W {/} -» /[(vjc)P')] : 5' w {/} [[P]] : 5 -> [[P']] : 5' 

PsP' match(5i, S[) P' : S\ Q' : 8' 2 Q' = Q match(<^,£ 2 ) 

P:S ] ^Q:S 2 (R-EQV) 

P= ff P' matcKSuSQ F :S\->Q: 8 2 P:S { ^Q:5 2 _ , 

■ (R. Alpha) (R.Exec) 

P : 5x -» Q : 5 2 E{P} : <5i -> E{g) : 5 2 

Figure 4: Reduction semantics for processes and states. 
a ::— e\r\a\a\a\a\a^±)a 
Figure 5: Syntax of actions. 



of process. The rule (R.EXEC) allows reduction to happen inside arbitrary execution contexts. 



4.3 Labelled Transition Semantics 

The reduction relation defines the interactive behavior of processes relative to a context in which they are 
contained, however, it covers only a part the behavior of processes, i.e., their local evolution. In other words, 
the reduction semantics describes how a process may interact with another, but not how this process (or parts 
of it) may interact with the environment. A labelled transition system describes these possible intraactions of 
processes with the environment. It is easy derive labels from the reduction semantics given in Figure @] We 
first define the substitution as a (partial) function G : (N — > N) W (V — > P) from names to names and process 
variables to update?: calculus process. We write P9 the image under the substitution 6 of process P. 

To make a transition means that a process P can evolve into a process Q, and in doing so perform the action 
a. Actions are given by the grammar in Figure |5l where input and output describe interactions between an 
agent and its environment, while a special r denotes interaction or silent action. Roughly speaking, transitions 
labelled with r correspond to the plain reduction relation. Action e, which a \ a = e, is introduced to signal the 
complete match of messages with an input pattern in a trigger. By definition, the parallel operator | on actions 
is associative and commutative, and has e as a neutral element. The multiset of actions is defined with the 1+1 
operator, i.e. a Mi a, which enforces the sequential execution of two actions. 

In LTS semantics in Figure |6l one first can note that in the labelled transition relation (in Figure [6]>, a(n), 
a{P), l[P] and up (I, P) all give rise to a out transition which respectively has a, a, I and up as channel name. 
Specially, no continuation is to afflicted each output action because we consider the output process is parallel to 
other processes, so all of these out transition will evolve out processes to 0. Second, all types of input actions 
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Figure 6: Labelled transition system semantics for processes. 

(e.g., a(x), a(X) and up(k, X)) or located resources (e.g., 1[X]) will lead the bound names of an objective 
process to be substituted by the names in x or processes in X. Specially, in rule (T.Update.Ok), the process 
Q in location k is triggered to execute some well-defined update operations, noted by the substitution process 
Q9, and the accompanied process R is evolved to a blocked process R9. Third, the rules (T.Nu), (T.Blk), 
(T.Par.L), (T.Par.R), (T.Seq.Fst) and (T.RES)signal that the transition of a process is not affected by 
v restriction, block restriction, parallel or sequence operation and passivation. But it is also noted that the 
evolution of successive process must be triggered after a successful execution of its antecedent process, as in 
rule (T.Seq.Both), where an explicitly temporal order is expressed between them. 

5 Related Work 

In general, the systems being updated dynamically are typically safety-critical, so it is important to select 
suitable timing of update to enable correct evolution of updated system. To make sure that the update is 
not performed while executing a specific code region, update authors can specify safe update points (H or 
mark blocks of code that must be entirely executed on a single version of the system [51, as described in our 
update system which provides formal semantics to reduce safe update points. While these approaches have 
been effective in some real-world scenarios, they potentially suffer from a structural problem. Update safety 
constraints are hard-coded in the original version of the system and cannot be modified at update time. Thus 
in this paper, we provide formal semantics to reduce safe update point. 

In O, Bierman et al. proposed a typed /t-calculus, named by Update, to reduce dynamic software update, 
which multiple versions of a software component can co-exist in system. This method is relatively intuitionistic 
but difficult to implement owing to the requirement of multi-version coexist at one time. Similar to the idea in 
our method, Stoyle et al.[ 13] developed a formal Proteus calculus to model dynamic update C-like programs, 
which assumed a new version has special signature different from its old version and all of updates are provably 
safe and consistent. Different from our method, these existing approaches have largely neglected some other 
important aspect, such as state preservation and transformation, possible update failure and recovery, while 



focusing more on the executing process of update. 

The ground ideas on our calculus inherit from some extended higher-order process calculi, e.g. M- 
calculus lfTTI and Kell-calcurus lfT2l . and specially the component-based software paradigm is represented with 
passivation which is similar to Kell-calculus. In complex systems, different updates may require very different 
conditions to be applied. When considering several categories of updates, the notion of transactional version 
consistency! 13 ] can be generalized throughout the entire lifetime of a software system. In |[T6l . the authors 
presented a calculus for modeling long running transactions within the framework of the 7r-calculus, with sup- 
port for dynamic compensation as a recovery mechanism. In our calculus, the failure recovery of an update 
apply a similar mechanism to this dynamic compensation. 

6 Conclusion and Future Work 

In this paper, we propose a dynamic update calculus, updaten calculus, based on extended higher order process 
calculi to model dynamic update of component-based software. The updaten calculus is an attempt to extend 
the higher-order n calculus with passivation, and to enhance it, through the introduction of a family of dynamic 
component update mechanisms. The calculus focuses on the following main concepts: the feasible granularity 
of update, timing selection of dynamic update, state transformation between versions, possible update failures 
and recoveries. We describe a series of rule on safe component updates to model some general processes of 
dynamic update and discuss its reduction semantics coincides with a labelled transition system semantics that 
illustrate the expressive power of these calculi. 

In general, state mapping problem is undecidable[6 ], but this does not mean that there is no any possibility 
to solve this problem automatically or semi-automatically[2]. In future works, we will manage to propose 
approaches to make us closer to achieve more practical and reductive state preservation and transformation. 
Furthermore, in a component-based system, it is relatively probable to cooperatively update several constituent 
components and some relative problems on this have been researched. So we will attempt to implement the 
cooperative update mechanism in future version of updaten calculus. And also we will study the notions of 
bisimilarity and equivalence for the updaten calculus, and discuss and prove some corresponding conclusions. 

Acknowledgements 

This paper is partially supported by the National Natural Science Foundation of China (NSFC) under Grant 
No.60673116, 60970010, the National Grand Fundamental Research 973 Program of China under Grant 
No.2009CB320705, and the Specialized Research Fund for the Doctoral Program of Higher Education of 
China under Grant No.200900731 10026. 

References 

[1] S. Ajmani: Automatic software upgrades for distributed systems. PhD Thesis, Massachusetts Institute of 
Technology, Cambridge, MA, 2004. 

[2] R. A. Bazzi, K. Makris, P. Nayeri, and J. Shen: Dynamic software updates: The state mapping problem. 
In HotSWUp 2009. 

[3] G. Bierman, M. Hicks, P. Sewell, and G. Stoyle. Formalizing dynamic software updating. In USE 2003. 

[4] C. Boyapati, B. Liskov, L. Shrira, C. Moh, and S. Richman: Lazy modular upgrades in persistent object 
stores. In OOPSLA 2003. 

[5] C. Fournet, F. L. Fessant, L. Maranget and A. Schmitt: JoCaml: A language for concurrent distributed 
and mobile programming. In Proc. Advanced Functional Programming 2002. 



[6] D. Gupta, P. Jalote, and G. Barua: A formal framework for on-line software version change. IEEE TSE, 
22(2), 1996. 

[7] M. Hicks and S. Nettles. Dynamic software updating. ACM Trans. Program. Lang. Syst., 27(6), 2005. 

[8] I. Neamtiu. Practical dynamic software updating. PhD thesis, University of Maryland, College Park, 
August 2008. 

[9] I. Neamtiu, M. Hicks, J. S. Foster, and P. Pratikakis: Contextual effects for version-consistent dynamic 
software updating and safe concurrent programming. In POPE 2008. 

[10] I. Neamtiu and M. Hicks: Safe and timely dynamic updates for multi-threaded programs. In PLDI 2009. 

[11] A. Schmitt and J.B. Stefani: The M-calculus: A higher-order distributed process calculus. In POPE 2003. 

[12] A. Schmitt and J.B. Stefani: The Kell calculus: A family of higher-order distributed process calculi. In 
GC 2004. 

[13] G. Stoyle, M. Hicks, G. Bierman, P. Sewell, and I. Neamtiu. Mutatis Mutandis: Safe and predictable 
dynamic software updating. ACM Trans. Program. Lang. Syst., 29(4), 2007. 

[14] S. Subramanian, M. Hicks and K. S. McKinley. Dynamic software updates for Java: A VM-centric 
approach. In PLDI 2009. 

[15] P. Sewell, G. Stoyle, M. Hicks, G. M. Bierman and K. Wansbrough. Dynamic rebinding for marshalling 
and update, via redex-time and destruct-time reduction. The Journal of Functional Programming, 18(4), 
2008. 

[16] C. Vaz and C. Ferreira and A. Ravara: Dynamic recovering of long running transactions. In TGC 2008. 
[17] L. Veiga and P. Ferreira: Asynchronous complete distributed garbage collection. In IPDPS 2005. 



